Information systems and computer network infrastructures currently under development are now being built with consideration for what constitutes an acceptable risk (or adequate protection). System assets, such as the hardware, software and system nodes of a computer network, must be protected to a degree consistent with their value. Additionally, these assets must be protected only until the assets lose their value. Any security features and system architecture should also provide sufficient protection over the life of the processed data. To assess whether or not any risk associated with a network is acceptable, a security engineer typically gathers all pertinent information, and then analyzes the risk associated with the network.
Risk analysis is a complex and time consuming process, which is necessary to determine the exposures within a network and their potential harm. As an example, when analyzing the security risks in a computer network, the security engineering typically follows the following steps:
1) Identify assets of the overall computing system.
2) Identify vulnerabilities of assets. This step typically requires imagination in order to predict what damage might occur to the assets and from what sources. The three basic goals of computer security are ensuring secrecy, integrity and availability. A vulnerability is any situation that could cause loss of one of those three qualities.
3) Predict likelihood of occurrence (exploitation), i.e., determining how often each exposure will be exploited. Likelihood of occurrence relates to the stringency of the existing controls and the likelihood that someone or something will evade the existing controls.
4) Compute any uncovered cost per year (expected annual loss) by determining the expected cost of each incident.
5) Survey applicable controls and their costs.
6) Project annual savings of control.
This last step of the analysis is a cost-benefit analysis, i.e., does it cost less to implement a control or to accept the expected cost of the loss? Risk analysis leads to a security plan, which identifies responsibility for certain actions to improve security.
Today, the rapid evolution of technology and proliferation of computers with increased power mandate the use of commercial-off-the-shelf (COTS) hardware and software components for cost effective solutions. This strong dependence on COTS implies that commercial grade security mechanisms are sufficient for most applications. Security architectures, therefore, must be structured to build operational, mission-critical computer systems with relatively weak COTS components. Higher assurance components can be placed at community or information boundaries, forming an enclave-based security architecture that implements a defense-in-depth approach to information assurance.
There are some design tools, i.e., software programs, available to the system architect to assist in maximizing the available protection mechanisms while remaining within the development budget. Current generation risk analysis tools usually are single vendor solutions that address a particular aspect or aspects of risk. These tools tend to fall into one of three categories:
1) Tools that work from documented vulnerability databases and possibly repair known vulnerabilities. Tools of this type are vendor-dependent for database updates, either through new product versions or by a subscription service. Examples from this category include ISS' Internet Scanner, Network Associates, Inc.'s CyberCop and Harris' STAT.
2) Monolithic tools that use various parameters to calculate a risk indicator. These tools are difficult to maintain and hard to keep current with the rapidly evolving threat and technology environment. An example of this tool category is Los Alamos Vulnerability Assessment (LAVA) tool.
3) Tools that examine a particular aspect of the system, such as the operating system or database management system, but ignore the other system components. SATAN, for example, analyzes operating system vulnerabilities, but ignores infrastructure components such as routers.
The use of multiple tools from a variety of vendors for a single computer network analysis is a labor-intensive task. Typically, a security engineer will have to enter a description or representation of the system (network) multiple times in multiple formats. The security engineer then must manually analyze, consolidate and merge the resulting outputs from these multiple tools into a single report of a network's security posture. Afterwards, the security engineer can complete the risk analysis (calculating expected annual loss, surveying controls, etc.), and then repeat the process to analyze alternatives among security risks, system performance, mission functionality and the development budget.
Also, none of these tools use an aggregate “snapshot” approach to the system with a “drill down” or layered approach to facilitate how one addresses risk at various layers (network, platform, database, etc.) of the system. These tools provide little assistance to system designers when analyzing alternatives among security risk, system performance and mission functionality. Instead, a “risk solution” is provided that addresses the particular aspect of risk that a given tool was designed to calculate. To develop a comprehensive risk assessment, a security engineer would have to become proficient in the use of several tools and manually correlate the resulting outputs.
One aspect of successful risk analysis is a complete and accurate accumulation of data to generate system models used by the analysis tools. Many current risk analysis tools depend on surveys filled out by users, system operations personnel, and analysts to acquire the data for development of a system model used in the analysis. Alternatively, a tool can actively scan a computer network to test various vulnerabilities against system components.
However, these methods have drawbacks. Textual or survey-based knowledge solicitation techniques are labor intensive and potentially tedious for the analyst. Many of the existing tools reuse the same information to analyze different aspects of the system security. It would be more advantageous to use a centralized repository of modeling data, which could provide a basis for shared inputs among existing tools. This repository could be used to generate data sets for use by risk analysis tools, allowing multiple tools to be run against the same system without separate input activities, thus reducing the possibility of operator error. The use of multiple risk analysis reasoning engines, or backbends, would allow various aspects of the system to be analyzed without the cost of developing one tool to perform all types of analysis. Integration of the information and the resulting informed assessments available by applying multiple tools would produce a more robust and accurate picture of a system's security posture. These results can facilitate more informed system design decisions, providing a framework for alternative evaluation and comparison.